昨天你剛接下這個爛攤子。今天，你就要面對第一個「來不及想」的時刻。

早上八點十五分：災難已經發生

你的手機在震。HR 總監站在你的位子旁邊，臉色發白。

「薪資系統跑不出來。今天是發薪日。」

你打開監控面板，心沉了下去。薪資批次作業（payroll batch job）已經跑了三小時，卡在某個步驟不動。正常情況下，這個作業應該在凌晨兩點完成。現在是早上八點，三千多名員工打開帳戶，會看到一片空白。

你開始查 log。在凌晨一點四十五分，有一筆變更記錄：

[2026-07-23 01:45:12] Config updated: payroll_db_timeout = 30 -> 5
Changed by: admin_generic
No approval ticket referenced.

有人把資料庫連線的 timeout 從 30 秒改成 5 秒。沒有 ticket、沒有審查、沒有通知。改動者是一個共用帳號，你根本不知道是誰。

薪資計算需要掃描大量歷史資料，5 秒根本跑不完，於是作業不斷 timeout、retry、timeout、retry……卡死在那裡。

你的 Slack 已經炸了。CEO 在問「什麼時候修好」，CFO 在問「是不是資安事件」，HR 在問「能不能先手動發一部分」。

你手上有兩個選項。

你的兩難

如果是你，你選哪個？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：為什麼 B 才是真正的解

你深吸一口氣，告訴 HR：「給我二十分鐘。」

你調出昨晚所有的系統變更記錄——不只是 config，還有程式部署、資料庫 schema、cron job 排程。你發現：

1. 連帶變更：同一時間，有人部署了新版的報表生成模組，裡面「順便」調整了資料庫連線池大小。
2. 隱藏相依：timeout 被改小，是因為有人想「加速健康檢查」，沒想到薪資作業也走同一個 config。
3. 真正原因：那個報表模組的新版本有 memory leak，會吃光連線池。有人想用「縮短 timeout」來掩蓋問題，結果引爆了薪資系統。

如果你選 A，直接把 timeout改回 30 秒，薪資「可能」會發出來——但報表模組的 memory leak 還在，下一個爆炸的會是客戶對帳系統，或更糟糕的東西。

你花了二十分鐘，做了三件事：

1. 回滾報表模組到前一版（修掉 memory leak）
2. 把 timeout 改回 30 秒
3. 重啟薪資作業，並把連線池參數微調大一點

早上九點，薪資批次完成。員工收到錢。沒有第二次爆炸。

真正的問題：變更點是「隱形的」

這不是「誰改錯」的問題。這是「改動沒被當成一件需要被看見的工作」的問題。

在這個系統裡：

• 任何人都能用 admin_generic 帳號改 production config
• 沒有變更審查流程
• 沒有影響範圍評估
• 沒有 rollback plan
• 改了之後，沒有通知、沒有記錄、沒有責任歸屬

這就是《鳳凰專案》第一部的核心困境：變更像「隨機事件」一樣發生，沒人知道、沒人管，直到炸了才回頭找。

Bill Palmer 後來的解法是建立 Change Advisory Board (CAB)——一個「變更審查會」。聽起來很官僚，對吧？但它的本質不是拖慢你，而是讓每個變更在進入 production 之前，必須回答三個問題：

1. 這改動會影響哪些系統？（相依性分析）
2. 如果失敗，怎麼退回來？（rollback plan）
3. 誰負責？誰需要知道？（責任與通知）

這不是「多一層審批」，這是「讓變更從隱形變成可視」的最低要求。

如果你有 AI Agent：災難在發生前被攔下

2026 年，這個場景可以完全不同。

想像一下：昨晚那個工程師準備改 config 時，他的改動必須走一個 Pull Request。當他送出 PR 的瞬間：

graph LR
    A[工程師改 config] --> B[AI Reviewer 掃描]
    B --> C{影響分析}
    C -->|發現| D[薪資作業會受影響]
    C -->|發現| E[報表模組有新版本]
    C -->|發現| F[連線池參數改變]
    D --> G[自動標註風險等級:HIGH]
    E --> G
    F --> G
    G --> H[要求人類審查 + Rollback Plan]

AI Agent 會在合併前警告他：

⚠️ 高風險變更偵測

你修改的 payroll_db_timeout 會影響以下服務：

• payroll_batch_job（關乎發薪，每月執行）
• customer_reconciliation（每日執行）

同時偵測到你有部署新版 report_generator，該模組在 staging 環境出現記憶體使用異常（+35% over 2 hours）。

建議：先修復 report_generator 的 memory leak，再調整 timeout。或者，將此變更拆成兩個 PR，分開測試。

災難在發生前，被攔下了。

這不是科幻。這是 2026 年真實可用的技術：

• 靜態分析 + 相依性圖譜：AI 掃描 config、code、infra-as-code，建立系統影響地圖
• 異常偵測：在 staging 環境抓到 memory leak
• 歷史學習：從過去的 incident 學會「哪些變更組合是危險的」

現場推演：一次沒通知的 Schema Change

再看一個業界很常見的場景（綜合改編，非特定公司）：

某個資料團隊在週五晚上，把一張資料表的 customer_id 欄位改名成 cust_id。他們測試過，自己的 ETL pipeline 已經更新，沒問題。

週一早上，三個部門的 dashboard 同時爆炸：

• 業務部門的「本週新客戶數」報表：column "customer_id" does not exist
• 財務部門的「應收帳款追蹤」報表：column "customer_id" does not exist
• 行銷部門的「廣告投放 ROI」報表：column "customer_id" does not exist

整個早上，三個部門的主管在 Slack 上瘋狂 @ 資料團隊：「我們的 dashboard 全掛了！」

問題不是「誰改錯」，問題是：

• 改動沒有被記錄成「一次變更請求」
• 沒有影響範圍分析
• 下游的三個團隊根本不知道有人在改 schema

最後，他們花了兩天回滾、修復下游查詢、重新部署。如果這個 schema change 在改之前，走過一次「變更審查」，AI 或人類都能在五分鐘內發現：「欸，這張表有 23 個下游查詢，全部用 customer_id 這個欄位名。」

今日金句

變更管理不是拖慢你的官僚，是讓你不必在發薪日早上禱告的保險。

留給你的問題

你的團隊上一次「小改動釀大禍」，是因為改錯了，還是因為 沒人知道有人在改？

如果你的答案是後者，那你需要的不是「更小心的人」，而是「讓變更可視化」的機制。

明天，我們來聊聊更隱形的災難：那些「不是壞掉，但變慢」的系統。當所有工程師都在救火，誰來修那些「還能用但快要死」的東西？

系列文章:

• Day 1: 你敢不敢接下這個爛攤子？
• Day 2: 你的第一個週一，該滅哪把火？(本篇)
• Day 3: 預告——你敢不敢在大家都在忙的時候，叫一個人去修「沒人抱怨」的技術債？